sasecurityfandomcom-20200214-history
SateLites
Category:Sasecurity back to http://scratchpad.wikia.com/wiki/Sasecurity TableOfContents } MTU issues IPcop } document lates If what Brendan is suggesting is true then you could use a Mikrotik router (demo mode should do it) to Mangle the packets to the required MTU see www.mikrotik.com > this is almost certainly an MTU issue. > For clients not connected directly to the gateway node you may see > problems (I did anyway ) with certain sat systems (Direcway 4020 in my > case which has an underlying MTU of 580) > > LW Knows about it for at least 6 months but has yet to resolve the > issue, don't hold your breath ! > > try setting the MTU on the gateway eth0 port to 580 and see if the > problem goes away (NOTE MTU of 580 may not be correct for your > particular setup) > > if that fixes it add the following line to the end of > * /etc/init.d/rc.local ifconfig eth0 mtu 580 > you only need to do this on the gateway > > We have a customer who is trying to access one of his suppliers web > > sites in order to order stock. Half way through the order he > > goes to a specific page and the page fails to successfully > > load. We have successfully accessed the page from a PC between > > our gateway node and the satellite link, and we can > > successfully access the site from an PC sat on the ethernet > > port of a meshbox (non gateway), however we can not > > successfully access the site if we connect to the same mesh > > box via a wireless ethernet bridge. > > > > My past experience , not with wireless, would suggest an MTU > > problem. > We have a customer who is trying to access one of his suppliers web > sites in order to order stock. Half way through the order he > goes to a specific page and the page fails to successfully > load. We have successfully accessed the page from a PC between > our gateway node and the satellite link, and we can > successfully access the site from an PC sat on the ethernet > port of a meshbox (non gateway), however we can not > successfully access the site if we connect to the same mesh > box via a wireless ethernet bridge. > > My past experience , not with wireless, would suggest an MTU > problem. > > > Comments and suggestions please. we have several issues of those kind in our deployments.... we investigate a lot and are now ready to shhare this exoperioence surely as we succeeded in reprioduce the issues and fix them. Observation: 1 - A gateway node directly connected in back2back eth with a sat modem and 3 repeaters linked wirelessly to the gateway. MTU hasn't been changed from the default The client A connected wirelessly to a repeater coulnd't surf very well . Tcp connection seems to be reseted and dropped or disconnected Client B is directly connected to the gateway in wireless. He has no issue to surf. all transfers are ok. leechtest from repeater nodes are failing in 90% of the time after transfering several kb. leechtest on gateway node are okay. Investigations: A datagrams analysis on the gateway , repeater and clients are showing a fragmentation problem whit client A. However no fragmentation problem with client B... In looking deeper, we saw the gateway was loosing ipfrag_time bits in datagrams when natting from wireless tunnels to the eth. Deeper again we understood the problem was in ipfrag bits stacks and NAT + TUNNELS. When Client A (connected in wireless repeater) is surfing on the net, his datagrams are encapsulated in TUN0 interface with a MTU change from 1500 (Wlan0 interface) to 1450 (TUN0), then going through the Tunnel toward the gateway. At this time datagrams is supposed to be translated in the eth0 address (NAT rules) of the gateway and then changing the MTU from 1450 to 1500... We noticed then when we add a passive or active network equipment between the gateway and the modem (eg: hub, switch, router or a Linux IPCop distro) it fixes the problem. Which means there is definitivly a problem with NAT/fragmentation causing some MTU problems on a gateway node directly connected in a Sat modem or in back to back eth connection eg: (MESHNODES <-- wireless links --> MESH GATEWAY <--eth cross-cable back2back--> MODEM) ...... Jérémy Lacroix -- Linux-Services Déploiement réseaux sans fils / logiciels libres / création web tel: 0870 21 4312 -- http://www.linux-services.fr/ > "Wireless" > > What I fail to see with Bredons suggestion, but I've not tried it yet, > is why the mtu on the gateway node would effect what is happening > on a remote node, and why on the remote node its works on the ethernet > but for wireless clients, unless there is some pmtu discovery stuff at > work. But as I said this does look like an mtu problem, although I > would have thought that if a wireless mtu problem existed we would see > it on intermesh boxes links because of the overhead of the tunnels and > encryption. Whilst I agree that it does not seem entirely logical that this should fix the issue, in my setup it did, I think that information concerning fragmentation isn't always getting passed back down the mesh and there may indeed be some PMTU issues. Since details of what happens in the mesh and how the various locustworld scripts configure everything is not well documented it's hard to make a complete diagnosis. I don't see why one would need to add a router (or why this would automatically help ) since the MTU can be set at the gateway, manually for testing then automatically on boot by adding the line * ifconfig eth0 mtu 580 * to the end of * /etc/init.d/rc.local this 'fix' will be broken any time you update the version using getandverify Why, if it's not a LWmesh issue do I not have any problems with my Staros links off this system or over my wired ethernet one other issue for us poor satellite victims is the need for the DNSchains to be set up so that we are using the Sat provider's proxyed DNS server instead of the locustworld one iwcconfig frag } daisy chain Category:Sasecurity back to http://scratchpad.wikia.com/wiki/Sasecurity >I believe there is some guidance on the wiki in setting up Aramiska >connections. Also, I think you have to use the "daisy chain" feature >that was built in especially for Aramiska connections and requires >dev84 or higher. You don't have to use the daisy chain feature, but it gives improved performance on satellite connections. The reason for this is that if the meshbox does DNS queries, each query for a new address will take 3 or 4 jumps across the satellite link - take the example of www.bbc.co.uk 1) Query the root servers for .uk 2) Query the .uk servers for .co.uk 3) Query the .co.uk servers for bbc.co.uk 4) Query the .bbc.co.uk server for www.bbc.co.uk Each one of these queries will add latency. What quite often happens is that a client's first DNS request will time out, but the second request will give the answer. Running with daisy chaining, each meshbox will pass the request to the satellite provider's DNS server, which should be optimised to send the request to a server at the downlink site. This will do the recursive lookup with no latency, and then send the answer back - thus only one satellite hop. Redirecting mail traffic out not by the default gateway We have done exactly this at Rural-WEB, and though a bit of a phaff to set up, works well. Three basic steps: 1) Direct port25 on the gateway attached to the ADSL gateway to point tothe node attached to the Aramiska end-station 2) direct port 25 on the Aramiska connected node to point to 192.168.1.1 (This allows you to redirect any mail coming in across the Mesh to be redirectable at this point too) 3) open up your firewall on the Aramiska attached node for port 25 This is what we had to do and it works brilliantly. I beleive the WiKi to be accurate (as we wrote half of it). If you want to get in touch directly we'll try and help you pronto. Cheers, Bertil. (At work for now, but on behalf of Rural-WEB.org) > I hope someone can help resolve an issue we have encountered today. > > Today we have installed a new ADSL (Zen) gateway on one of our mesh > nodes to be used as the primary internet gateway. Previous to this we > only had one connection via an Aramiska satellite connection (on a > different node). However, we need to send mail out via the Aramiska > connection as this is where the mail server is. > > We have followed the directions in the Wiki (Redirecting traffic out not > by the default route), without success. Neither POP3 nor SMTP work. > > We have managed a work around using the Aramiska server external address > and the Zen SMTP server. But we need our local mail working. > > Can anyone suggest what is wrong? Our mail server is on internal address > 192.168.1.1.